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ABSTRACT 

One of the SODS (space operation and 
data system) sub-systems, NP (network 
planning) was the first expert system 
used by NAS DA (national space 
development agency of Japan) for 
tracking and control of satellite. The 
major responsibilities of the NP system 
are: first, the allocation of network 
and satellite control resources and, 
second, the generation of the network 
operation plan data (NOP) used in 
automated control of the stations and 
control center facilities. Up to now, 
the first task, of network resource 
scheduling, has been done by network 
operators. NP system automatically 
generates schedules using its knowledge 
base, which contains information on 
satellite orbits, station availability, 
which computer is dedicated to which 
satellite, and how many stations must 
be available for a particular satellite 
pass or a certain time period. This 
paper introduces the NP system. 

Key words: NP system, knowledge base, 
flexibility, conflict solving, expert 
systems 

1. INTRODUCTION 

This paper introduces the NASDA network 
planning (NP) system. Since NP system is 
a Type-1 SODS sub-system we start with 
a brief explanation of SODS. 

1.1 Development of SODS 

The type-1 SODS, which is the ground- 
station-based tracking and control 
system, has been in partial operation 
since the launch of JERS-1 (Japan earth 
resources satellite-1) in 1992. NASDA 
started to develop a SODS long-ranged 
tracking and control system, in 1987. 


The type-1 SODS is the first step in the 
development. In the early stages, we 
expected two new requirements for 
satellite operation. One is for 
simultaneous operation of more than 
three sun-synchronous sub-recurrent 
polar satellites (JERS-1, MOS-1 : marine 
observation satellite- 1 and MOS-lb), 
MOS-1 and MOS-lb were launched in 1987 
and 1990. The other requirement is for 
double launch operations for use with 
the H-II rocket to go Into opration in 
1995. NASDA automated ground network 
control to meet these needs. NASDA also 
automated the scheduling of the ground 
network and planning file transmission. 

1.2 Network Planning System 

The NP system allocates network and 
satellite control resources for each 
satellite. NP then generates data for 
the network operation plan (NOP) used 
in the remote control of the stations 
and in configuration of control center 
facilities. The NOP flow chart is shown 
in Fig.l. NOP data, which based on the 
operation requests sent from network 
users through the NM (network management 
system) referring to the station event 
data (such as visibility information and 
periods when operation is under 
constraints), is transferred to TC 
(tracking network control system) and LC 
(communication line control system). 
This data is used by TC for the station 
control and by LC for the communications 
line control. 

1.3 Developing NP policies 

We considered several requirments when 
developing the NP system. One was the 
store and inheritance of know-how on 
network planning from experts in the 
field. More complicated and more 
frequent operations make it more 
difficult to store and inherit the 
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Fig. I Data flow for the network operation plan 


know-how. Another consideration was that 
scheduling could be simulated in some 
situations. Combining these factors, we 
introduced an expert system to NP. 

1.4 Computer Technology 

Type-1 SODS used a variety of new 
equipments, including engineering work 
stations (EWS), and a local area 
network (LAN). The NP system is the 
first expert system introduced in 
NASDA’s tracking and control operations. 
Recently, expert systems have proven 
capable of using their inference 
capability for judgement and reducing 
part of the workload of an operator. 
Generally, expert systems can be 
classified into four groups: diagnostic, 
for medical patients or machine 
troubles; forecasting, for financial 


affairs analysis; control, for factory 
automation or fuzzy systems; and design 
and planning, for electric circuit 
design, construction of computer systems, 
and planning travel courses. The 
configuration of the NP system 
corresponds to the planning type. 

2. FUNCTIONS OF THE NETWORK PLANNING 
SYSTEM 

2.1 Knowledge Base 

The NP system relies on a knowledge base 
data constructed from the know-how of 
human experts. We divide this knowledge 
base into ‘definitions’ and ‘tables’. 

2.1.1 Definitions 

Definitions are of resources (satellites 


436 









in operation, network facilities, etc*)* 
operation priorities, and satellite 
priorities* The NP system uses these 
definitions for scheduling* The 
operator must define the resources to 
be used before scheduling an operation* 
Definitions contain the following 
info rmat ion* 

(1) Priority 

The NP system’s knowledge base uses two 
forms of priority: operation (launch, 
maneuver, usual, ...) and satellite* 

Each plan is established in the order of 
operation priority* When operation 
priorities are equal, each plan is 
established according to satellite 
priority. 

(2) Satellite 

Information is included for each 
satellite (ID, name, type of orbit, 
time margin of equipment preparations)* 
This Definition is important for 
scheduling* The NP system changes the 
scheduling method in accordance with 
satellite orbits. Operation time is also 
decided by the required time for the 
station facility set-up. 

(3) TACS (tracking and control station) 
TACS information containing TACS name, 
TACS ID, and TACS type (domestic or 
foreign). 

(4) TACS Antenna 

TACS antenna definitions including 
antenna name and antenna type (X-Y or 
AZ-EL). 

(5) TACC (tracking and control center) 
facilities 

Contains TACC facility name and ID. 

(6) SOCS (satellite operation and 
control system) 

Includes SOCS name and ID. 

(7) Station/pass combination definition 
For sub-recurrent polar orbit. Defines 
station/pass combination pattern in 
detail. Some examples of this pattern 
are showen in Fig. 2. More patterns are 
used in actual operation. 

2,1.2 Tables 

Tables indicate how to use resources, 
which computer is dedicated to which 
satellite, and how many stations must 
be available for a particular satellite 
pass or a certain time period. Each 
table has ‘flexibility’ for an optimal 
schedule where flexibility is expressed 
as the preferred order of facility 
allocation which are defined above. 
Using flexibility, when a facility 


ex.l) 2 pass operation 



Fig. 2 Station/pass combinations 


cannot be used due to conflicts, 
alternate facilities are assigned. A 
table is constructed for each satellite. 
Tables are constructed for the 
following information. 

(1) Preferred operation day 
Prioritizes scheduling days for 
geostationary orbit. 

(2) Preferred operation time 
Prioritizes operation times for 
geostationary orbit. 

(3) Preferred ranging time 
Prioritizes ranging time. One ranging 
unit is a quarter for each one hour, for 
geostationary orbit. 

(4) Preferred facilities 

Gives TACS antenna preferences for 
geostationary orbit. 

(5) Preferred SOCS 

Prioritizes SOCS for geostationary and 
sub-recurrent polar orbits. 

(6) Station/pass combination & activitie 
Prioritizes * station/pass combinations 
definition’ for sub-recurrent polar 
orbits. 

(7) Sub-recurrent orbit nominal pass 
Defines TACS antenna and pass 
pref errences , where pass information 
fits in to visible patterns for sub- 
recurrent polar orbit satellites. 

(8) Request code table (executive 
parameters & activities) 

This table serves two purposes: user 
services and facilitating the knowledge 
base. Users can request satellite 
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operations simply by using numbers from 
this table. Users are not required to 
choose the operation time or revolution 
number, these are established from other 
tables. This table also provides 
information for the knowledge base. When 
a request and other requests conflict, 
optimal plans are determined by this 
table. 

The request code table contains detailed 
request parameters and numbers from 
some of the above tables concerning 
request flexibility. The two orbit 
types considered are geostationary and 
sub-recurrent polar orbit. Table 
combinations are shown in Tab.l and 
Tab, 2, Since many table ID combinations 
are possible, numerous request code 
table preferrences are possible, 

2,2 Scheduling By Network Planning 
System 

As memtioned, the NP system establishes 
plans for knowledge database use. 
Requests are sorted by operation and 
satellite priority. NP system has three 
different planning modes for a variety 
of approaches for solving request 
conflicts. 


2.2.1 Scheduling Modes 

The NP system has three planning modes, 

(1) Rejection mode 

When a request conflicts with an already 
established plan, the request is just 
rejected. The request is regarded as 
4 NG, 1 and is unavailable for operations. 

(2) Solving selection mode 

When a conflict occurs, operators can 
select the conflict solving method. The 
methods are 1 cut & try, 1 4 priority 
exchange, 1 ‘backup code 1 and 1 rejection. 
1 These methods are explained in 2.2.2. 
Method selection allows efficient 
planning and can produce a tight fitted 
schedule. 

(3) Automatic solving mode 

Unlike the solving selection mode, this 
mode needs no operator intervention. 
Conflicts are solved by a fixed 
procedure. First, cut & try is tried. 
Second, if a request becomes ‘NG 1 by 
cut & try, backup code is attempted. 
Lastly, if both cut & try and backup 
code fail, the request is put into 
rejection mode. 

The solving selection and automatic 
solving modes make the most of the 
flexibilities for solving request 
conflicts, and for improving schedules. 


Tab.l Geostationary orbit 


Request code table 


Preferred operation day table 
Preferred operation time table 
Preferred ranging time table 
Preferred facilities table 
Preferred SOCS table 


Form of request (lesser items) 

Term of operation 
Request code ID 

Operation class (referring to operation priority) 
Backup operation code ID (Cf. 2.2.2 conflict solving) 


Examples 

Nov. 12 to Nov. 20 
01 (2 TACS RNG operation) 
04 (Usual operation) 

03 (1 TACS operation) 


Tab. 2 Sub-recurrent polar orbit 


Request code table 


— Preferred SOCS table 

— Station/pass combination & activities table — 

— Station/pass combination definition 
— Sub-recurrent orbit nominal pass table 
Form of request (lesser items) Examples 

Day of operation ... Nov. 12 

Request code ID ... 01 (3 TACS operation) 

Operation class (referring to operation priority) ... 02 (Maneuver operation) 

Backup operation code ID (Cf. 2.2.2 conflict solving) ... 05 (2 TACS operation) 
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2.2.2 Conflict Solving Methods 

This section explains the conflict 
solving methods used by the solving 
selection and automatic solving modes. 

(1) Cut & try process 

We assume NP is processing “Request X." 

NP seeks available network facilities 
and operation time within the 
flexibility of “Request X.’ 1 Conflict 
then occurs. 

0 The group of already scheduled 
requests which conflict with “Request X" 
are cancelled. 

(2) “Request X" is scheduled. 

0 Available network facilities and 
operation times within the flexibilities 
of the cancelled requests are searched 
for. 

@ If cancelled requests cannot be 
scheduled , NP cancels “Request X fl and 
recovers the cancelled requests. 

(2) Priority exchange process 

The difference between cut & try and 
priority exchange is how they are done 
if a cancelled request cannot be 
rescheduled (as in @ below). By 
priority exchange, cancelled requests 
become ’NG. 1 

0 Already scheduled requests which 
conflict with “Request X" are cancelled. 

0 “Request X” is scheduled. 

0 Available network facilities and 
operation times within the flexibilities 
of the cancelled requests are searched 
for. 

(4) If the cancelled requests cannot be 
scheduled, NP does not recover the 
cancelled requests. “Request X" plans 
are left. 

(3) Backup code 

If a request cannot be scheduled, the NP 
system schedules using this backup code. 
For example, we suppose that the usual 
code designates 3 TACS operations and 
backup code designates 2 TACS 
operations. If 3 TACS cannot be 
established, then 2 TACS are scheduled. 
Of course, users are not always 
required to use the backup code. 

(4) Rejection 
Requests are rejected. 

2.3 Environment 

The NP system runs on an engineering 
work station (Fujitsu A-80). The 
operating system is UNIX (SX/A) and the 
principally used languages are C, LISP, 
and FORTRAN. The NP environment is shown 


in Fig. 3. 

j= Engineering work station — 

(Fujitsu A-80) 
CPU: 68030 (25MHz) 

Memory : 48MB 
Disk: 330MB x 2 


UN I X/OS (SX/A) 


Fujitu expert ESHELL/senser 
base* (ESHELL/SB) 

* multi-process control 


LISP, C, FORTRAN 


Fig. 3 Operating environment 


3. APPLICATION TO OPERATION 

NP operates according to the timeline of 
Fig. 4 

(1) Monthly scheduling period 

In this phase, the operator schedules 
activities such as facility maintenance, 
launches, and the operation plans for 
each satellite’s nominal orbit. This 
schedule is a base of weekly and 
emergency scheduling. Monthly network 
schedule lists are printed out. 

(2) Weekly scheduling period 

In this phase, the operator reconsider 
the monthly schedule in more detail for 
the given week. If problems occur, 
scheduling is executed again. Weekly 
network schedule lists are printed out. 

(3) Active scheduling period 

If a problem happens during this phase, 
the operator updates the schedules as 
emergency scheduling. A daily network 
schedule lists is printed out. 

4. CONCLUSION 

4.1 Evaluation of NP System Operation 

The NP system may be applied to a 
maximum of 28 satellites and 12 antennas 
with up to 99 operation codes per 
satellite. Results for scheduling three 
sub-recurrent polar orbit satellites 
were satisfactory. Before the launch of 
JERS-1, there were only two polar 
satellites whose visible time had very 
little overlap. However, the visible 
time of JERS-1 overlaps theirs so 
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Note: MNSL, WNSL, and DNSL are monthly, weekly, and daily scheduling lists. 


Fig. 4 Timeline of NP operation 


heavily that the scheduling becomes much 
difficult. The NP system needs only 
about two hours to schedule a monthly 
plan. If manually, such a scheduling 
would require about one day. The NP 
system improves work efficiency and 
makes schedule list generation easy. 
This NOP allows timely scheduling and 
automated functions. 

4.2 Expert System Effects 

By using the change information in the 
knowledge base, users can make the most 
efficient use of the facilities. 
Moreover, by accumulating change 
information in the knowledge base, 
operating satellites, expert know-how is 
left and used successively. Scheduling 
simulations can be done easily for 
satellites or new facilities. 


4.3 End-User Services 

The monthly network schedule list 
includes the facility maintenance plan 
while the daily network schedule list 
gives information of backup passes. 
End-Users can use these lists for 
making requests . 

4.4 Improvement 

At now, the knowledge base of the NP 
system is updated according to the 
suggestions and requirements from the 
operators and the users. We hope to 
continue the effort to improve the NP 
system so that it can schedule more 
comp 1 icated requests including 
international cooperations. 
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